Computer systems have permeated much of everyday life. This is particularly true in business environments where computers are widely used for document preparation using word processor programs. Financial information is manipulated using accounting spread sheet programs which display the information in various graphical forms. Graphical information is very readily assimilable by an individual, and can be more intuitively, and therefore, more quickly understood than by the mere reading of text and tables.
The concept of graphical presentation of information has even gone so far as to be used in the preparation of programs which historically have been written as text on keyboards. Examples of graphical program generators include U.S. Pat. No. 4,315,315 issued to Kossiakoff for GRAPHICAL AUTOMATIC PROGRAMMING. This concept of a block diagram program system is further illustrated by U.S. Pat. No. 4,868,785 issued Sep. 19, 1989 to Jordan et al. for BLOCK DIAGRAM EDITOR SYSTEM AND METHOD FOR CONTROLLING ELECTRONIC INSTRUMENTS. The control of electronic instruments through a graphical user interface is also provided by a product known by the proprietary name "LabVIEW" produced by National Instruments of Austin, Tex. These systems demonstrate the desirability of working with graphical images rather than textual information, particularly when systems become complex and large in size.
An environment in which there has remained a lack of application of graphics in a significant sense has been the analysis and testing of integrated circuit designs and devices.
Many commercial products take advantage of mass produced integrated circuits which have proven functionality to provide desired device operation. However, desired functionality and speed are not often readily achieved with these devices. As a result, application specific integrated circuits (ASIC's) and very high speed integrated circuits (VHSIC's) are used. ASIC's generally have 8,000 or fewer gates. VHSIC's may have 50,000 or more gates. Correspondingly sized commercially available devices will soon follow.
For each gate in a device, typically three to five vectors (ordered sets of data) are required to test each gate of such a device. Thus, for 5,000 gates, this means 15,000 or more vectors. Device pin counts vary between 64 and 256. The pin count also represents the number of bits per vector. Multiplying the number of bits per vector by 15,000 vectors results in generation of a million or more ones and zeroes to make up the vectors for testing. Each vector is created in software as a pattern of ones and zeroes representing device states. These device states, also viewed as waveforms, adjust the timing to test device specifications. The waveforms or states are additionally edited to reflect tester requirements for actual physical waveform generation and device testing.
This massive amount of stimulus data invariably must go through a series of rules, checks and modifications in the progression from design simulation to physical device testing. This problem is compounded as devices grow more complex.
During the process of putting an ASIC device on the market, several steps are involved. First, during a design phase, the concept of the design is reduced into schematic or other related form defining the overall design of the circuit. The design is then analyzed to verify the functionality of the design concept, typically through the use of software simulation. In simulation, models of the design are used to determine whether the captured design performs in a manner that meets the designer's original expectations. Many elaborate simulation models exist which produce an analysis of the design purely from a software viewpoint and are not related to any physical device characteristics, other than the known design functional characteristics of the device. During this simulation, extensive test data, typically as test vectors, are generated for testing the design concept.
Once the design satisfies the engineer as to its functionality and conformance with the design concept and objectives, design verification takes place. A prototype is typically built to determine whether the physical circuit conforms with the simulated design circuit. In most situations a test engineer independent of the design engineer performs the actual test. Conventionally, skilled test engineers use expensive, production-oriented automatic test equipment (ATE), or design engineers use computer-controlled clusters of instruments such as pattern generators, logic analyzers, power supplies, and other related devices. With a production ATE system, the engineer is often faced with inflexible programming, difficult access and high cost. On the other hand, using separate laboratory instruments is time consuming, difficult, tedious, and somewhat overwhelming in complex applications. This approach also often fails to uncover a large number of timing-related problems.
As a result of the need to convert simulation test files into prototype test files for running by a tester (ATE) it is necessary to modify the original simulation timing to meet specific limitations of a vendor's test hardware. Test vector translation stems from the need to convert the event-based test vectors used in simulation into the state or cycle based test vectors required by test hardware. Stimuli generated for simulation environments are normally event oriented. That is, after one event occurs, or at the same time as it occurs, another event, such as a signal transition, takes place. While the sequence of events is critical, the time between events is not. The occurrence of events is not constrained by a real time clock.
Unlike simulators, test hardware must cope with real time constraints. It generally operates as a synchronous, cycle-oriented machine. Consequently, it is driven by state-oriented data, with the signal behavior being controlled by a variety of signal conditioners that are constrained by test cycle boundaries. Depending upon the tester, the signal behavior may be controlled by a variety of different features, such as signal formats, real time edge specification, and variable length test cycles. Converting test vectors from event-oriented data to state-oriented data is a translation process. For each cycle of the tester, the event data is sampled to determine what the state of the tester should be for that cycle. For a general discussion of the issues involved in the design and testing of circuits, see Pieper, "The Myth and Reality of Linking Design and Test" Electronics Test, April 1988, pp. 55-59.
Commercial software translators have been developed to automate the conversion process. Setting up, or programming, the translator, however remains a manual process, and the quality of simulation conversion depends upon the quality of the translator setup. Such commercially known translators include a system referred to under the proprietary name of "TDS" made by Test Systems Strategies, Inc. of Beaverton, Oreg.; the systems identified under the proprietary names of SAV (stimulus analysis and verification), and ATOP (automatic test optimization program), provided by Compass Development, Inc. of San Jose, Calif.; and the system known by the proprietary name of "ATELink" of Simutest, Inc. of Santa Clara, Calif.
The TDS package of Test Systems Strategies, Inc. is representative of a relatively complex and comprehensive translator. It provides for the capability of reading in a file from a commercial simulator to make available the test vector structure used during the simulation. A simulation rules checker and tester rules checker determine whether the file data conforms to the specifications of the simulation and to the tester. In order to convert the simulation file into a tester file, as has been mentioned, the file must be conditioned. Waveform editors do this conditioning by allowing the user to enter specifications for changing the data into a form which is acceptable to the tester, except that the data manipulation is done entirely in an event mode format. Thus, the final test program is not available to editing or review. Subroutines are used to draw, using ASCII characters, a representation of the waveform for viewing on a screen. This presentation simply reflects the existence and status of the data and cannot be manipulated, except through the conditioner subroutines. Once the test engineer is satisfied that the data file is acceptable for translation into a test program, a test program generator designed for a specific commercial ATE is run to produce a test program for input to the tester.
This entire process is done through the use of menus and text editing on the screen. Control commands must be entered by inserting proper character strings to manipulate and activate the various system features. It can be seen that setting up a translator remains a manual process and the quality of simulation conversion depends on the quality of the translator setup. The quality of the setup is directly related to the size of the design, the capabilities of the tester, and the test experience of the person setting up the translator.
Thus, while vector-translators are a step in the right direction, the user must still supply a significant amount of knowledge to make them work. Further, it is desirable to have a system which is usable by both design engineers and test engineers, so that the design engineer can generate the necessary test files for testing basic and PCB (printed circuit board) prototype devices using commercially available testers. The test translation process typically involves a detailed understanding of the tester requirements and therefore is not readily undertaken by a design engineer. Further, a test engineer does not have the intimate and extensive knowledge of the intended function and workings of the prototype device, so that this information must be learned and obtained through information provided by the design engineer. It is therefore desirable to have a system which is usable by both design engineers and test engineers which allows them to interface between the two general functions without requiring the extensive background of knowledge typically required.
For a further discussion of these issues, see Pieper, "New Concepts for Test Stimulus Generation and Editing", Electronics Test, June 1988, pp 46-52.